System and method for maintaining presence and communicating over a computer network using the http protocol

ABSTRACT

A computer-implemented process facilitates communication with an entity over a network. A static HTTP URL is associated with the entity. Communications information reflecting the entity&#39;s current online presence including the entity&#39;s dynamic session information as determined using the HTTP protocol is linked with the URL. Communication with the entity is facilitated using the URL and the communications information. The forms of communication facilitated include type chat/instant messaging, voice communication over a computer network, video communication over a computer network, voice communication from a computer network to a telephone network and two-way text messaging to Internet enabled wireless devices.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a divisional of U.S. application Ser. No. 09/709,909filed Nov. 9, 2000, which claims the benefit under 35 U.S.C. § 119(e) ofU.S. provisional application Ser. No. 60/165,917, filed Nov. 17, 1999,the disclosure of which is incorporated herein by reference in itsentirety.

COPYRIGHT NOTICE AND AUTHORIZATION

Portions of the documentation in this patent document contain materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure as it appears in the Patent and TrademarkOffice file or records, but otherwise reserves all copyright rightswhatsoever.

BACKGROUND OF THE INVENTION

The present invention relates generally to a system and method formaintaining presence and communicating over a computer network using theHTTP protocol. More particularly, the present invention relates to asystem and method for maintaining communications information reflectingcurrent online presence including dynamic session information asdetermined using the HTTP protocol and using the communicationsinformation to facilitate communication over the computer network.

The usage of computer networks, particularly the Internet, has growndramatically and is expected to continue to grow at a rapid pace. Thissurge in network usage has brought with it a corresponding increase inthe prevalence and importance of real-time network communicationsmethods such as instant messaging / type chat, voice over Internetprotocol (VoIP) and video over Internet protocol. These methods andsimilar ones will play an increasingly important role in the waycomputers and people communicate.

In order for two computers to communicate using the Internet, a callingcomputer must know or be able to discover at least an Internet ProtocolUP) address of a callee. The Domain Name System (DNS) facilitates thisprocess by resolving (i.e., translating or converting) a “friendly name”(i.e., a recognizable set of characters rather than a numerical IPaddress) into a corresponding IP address. Thus, human users generally donot need to know or even see the underlying IP address associated withcomputers connected to the Internet or other computer networks.

Many Internet users access the network using a personal computer (PC)and an Internet Service Provider (ISP). It is a common practice for anISP to dynamically assign an IP address that is valid only during theinterval in which the PC is connected to the ISP. Furthermore, there isno static identifier associated with the computer and available throughDNS. Accordingly, in many instances, users do not know their owndynamically assigned Internet address, nor do they have a DNS nameassigned to their computer. As a result, most Internet users are unableto supply any static, unique identifier that can be repeatedly used toestablish a communications session with their computer via the Internet.

A mechanism referred to as User Location Service (ULS) provides onesolution to this problem. ULS includes a dynamic directory containingrecords that map some unique user identifier to a currently assigned IPaddress. ULS places no restriction (other than uniqueness) on theselected static name. Individual computers are responsible forcontacting and logging in to a ULS server. The act of logging in causesa new ULS record to be created. The ULS record is deleted when thecomputer logs out of ULS or fails to continue to refresh its record.

Two significant problems with ULS are its inability to scale and thecompletely non-standard way in which static names are resolved to IPaddresses. Using non-standard name resolution techniques preventspre-existing applications from accessing intermittently connecteddevices in an automated manner. For example, a ULS identifier stringcannot be resolved by DNS or by an individual's web browser software.Existing applications such as web browsers are typically only able toaccess resources using local file names, actual IP addresses, and DNSnames. To contact intermittently connected devices using prior arttechniques, the particular ULS server containing the address must becontacted to resolve the address. Thus, ULS registered devices aretypically not directly accessible using many existing applications.

The inability to scale well presents even greater problems. A computerwishing to resolve a ULS name has no way of knowing which ULS site maycurrently contain the proper record. There is no central authority underwhich all existing ULS sites may be automatically searched.Consequently, an exhaustive search of all available ULS sites iscurrently required. Worse yet, there is no current mechanism by which anapplication can determine the total set of ULS sites on a given day.Thus, newly added sites only further complicate an effort to locate auser having an unknown ULS connection.

Dynamic DNS provides another solution. Dynamic DNS is very similar toULS, except that dynamic DNS associates a static domain name (e.g.,usemame.thins.net) with a user's currently assigned IP address. As withULS, the act of logging in to a dynamic DNS system causes a new DNSrecord to be created associating the user's static domain name with theuser's current IP address. The DNS record is deleted when the computerlogs out or fails to continue to refresh its record. In this way, a userdesiring to communicate with another user logged in to a dynamic DNSsystem can perform a standard DNS lookup on that user's static domainname to ascertain the user's current IP address.

By replacing the non-standard name resolution techniques of ULS withstandard DNS naming, dynamic DNS solved some of the problems inherent inULS, However, there are still disadvantages to using dynamic DNS as ameans of locating and communicating with an intermittently connecteduser. First, dynamic DNS only provides a user's current IP address. Itdoes not provide complete dynamic session information for a user,including such information as a user's host box identifier, TCP portnumber on which to be reached, and session ID. Knowledge of a user'scomplete dynamic session information facilitates the use of multiplepossible forms of communication (e.g., type chat, voice, video, etc.).

Second, knowledge of a user's dynamic IP address through dynamic DNSonly allows for limited forms of communication. For example, a user cantake an IP address and communicate using an H323 protocol communicationsapplication such as Microsoft NetMeeting. A user could not, however,type the IP address into a web browser and communicate using the HTTPprotocol. The inability to allow HTTP communications is particularlydisadvantageous in that HTTP communications can take place even withusers located behind firewalls and proxy servers —security measures thatare growing more and more prevalent today. By contrast, H323communications will not easily function through a firewall, unlessapplication modifications are made.

Existing type chat/instant messaging applications are alsodisadvantageous in that they do not operate using the HTTP protocol.These applications typically require the download of large softwareprograms that operate using proprietary formats that are incompatiblewith one another, precluding the interoperability of the variousapplications. Moreover, the applications do not transmit messages usingthe HTTP protocol. Indeed, some do not even send messages usingTransmission Control Protocol/Internet Protocol (TCP/IP), the transportprotocol underlying the HTTP protocol and most other Internettransmissions, but instead use User Datagram Protocol (UDP). These typechat/instant messaging applications therefore do not function behindmost firewalls and proxy servers.

There is thus a need for a communications system that will allow theassociation of a static name with a user's complete dynamic sessioninformation. There is also a need for a communications system that willfacilitate multiple forms of communication with a user given knowledgeof only the user's static name. There is also a need for acommunications system that will facilitate multiple forms ofcommunication using the HTTP protocol, and thus will allow communicationwith users and devices located behind firewalls and proxy servers.

SUMMARY OF THE INVENTION

Briefly stated, the present invention provides a computer-implementedmethod of facilitating communication with an entity over a network. Inthe method, a static HyperText Transfer Protocol (HTTP) UniversalResource Locator (URL) is associated with the entity. The URL is linkedwith communications information reflecting the entity's current onlinepresence including the entity's dynamic session information asdetermined using the HTTP protocol. Communication with the entity isfacilitated using the URL and the communications information.

In another embodiment, the present invention provides acomputer-implemented method of facilitating communication over a networkwith one or more members of a group of entities, the group comprising aplurality of entities. In the method, a static HTTP URL is associatedwith the group of entities. The URL is linked with communicationsinformation reflecting each of the members' current online presenceincluding each of the members' dynamic session information as determinedusing the HTTP protocol. Communication with one or more members of thegroup is facilitated using the URL and the communications information.

In yet another embodiment, the present invention provides acomputer-implemented method of determining the current online presenceof an entity on a computer network. In the method, a static HTTP URL isassociated with the entity. The URL is linked with communicationsinformation reflecting the entity's current online presence includingthe entity's dynamic session information as determined using the HTTPprotocol. The current online presence of the entity is determined usingthe URL and the communications information.

In yet another embodiment, the present invention provides acomputer-implemented method for detecting and maintaining an entity'scurrent online presence on a computer network, the network including ahost computer. In the method, an HTTP request is sent from the entity tothe host computer to initiate an HTTP connection between the entity andthe host computer. Next, the request is received at the host computerand a socket is opened and maintained for the HTTP connection with theentity in a non-blocking manner without a new thread being created forthe HTTP connection.

Finally, at least one byte of data is sent from the host computer to thesocket at a specified interval to keep open the HTTP connection with theentity.

In yet another embodiment, the present invention provides acomputer-implemented method for detecting and maintaining the currentonline presence on a computer network of a plurality of entities, thenetwork including a host computer. In the method, a request is receivedat the host computer from one of the plurality of entities to establishan HTTP connection. Next, a socket is opened and maintained for the HTTPconnection in a non-blocking manner, the socket having a socket filedescriptor, with the one of the plurality of entities without a newthread being created for the HTTP connection. Next, the socket filedescriptor is added to a socket database, the socket databasemaintaining a list of open sockets with those of the plurality ofentities that are currently online. Finally, at least one byte of datais sent from the host computer to the open sockets in the socketdatabase at a specified interval to keep open the HTTP connections withthe plurality of entities.

In yet another embodiment, the present invention provides acomputer-implemented method of sending text messages from a first entityto a second entity over a network using HTTP, the network including ahost computer. In the method, a socket and an HTTP connection betweenthe second entity and the host computer is established and maintained.Next, a text message is sent from the first entity to the host computerto be delivered to the second entity. Finally, the text message is sentto the second entity from the host computer using the socket and theHTTP connection.

In yet another embodiment, the present invention provides acomputer-implemented method of transporting Session Initiation Protocol(SIP) messages from a first entity to a second entity over a network,the network including a host computer. In the method, a socket and anHTTP connection between the second entity and the host computer isestablished and maintained. Next, a SIP message is sent from the firstentity to the host computer to be delivered to the second entity.Finally, the SIP message is sent to the second entity from the hostcomputer using the socket.

Finally, in yet another embodiment, the present invention provides acomputer-implemented method of sending text messages from an entity toan Internet enabled wireless device over a network, the networkincluding a host computer. In the method, a communications request issent to the Internet enabled wireless device from the host computer thatincludes an URL identifying the host computer. A socket and an HTTPconnection between the Internet enabled wireless device and the hostcomputer is established and maintained using the URL. Next, a textmessage is sent from the entity to the host computer to be delivered tothe Internet enabled wireless device. Finally, the text message is sentto the Internet enabled wireless device from the host computer using thesocket and the HTTP connection.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description ofpreferred embodiments of the invention, will be better understood whenread in conjunction with the appended drawings. For the purpose ofillustrating the invention, there are shown in the drawings embodimentsthat are presently preferred. It should be understood, however, that theinvention is not limited to the precise arrangements andinstrumentalities shown. In the drawings:

FIG. 1 is a high-level architecture block diagram configuration for onepreferred embodiment of the present invention;

FIG. 2 is a functional flowchart of the steps to establish the onlinepresence of an entity in a preferred embodiment of the presentinvention;

FIG. 3 is a block diagram showing the functioning of a socket handler ina preferred embodiment of the present invention;

FIG. 4 is a functional flowchart of the steps to maintain the onlinepresence of an entity in a preferred embodiment of the presentinvention;

FIG. 5 is a functional flowchart of the steps to login an entity intothe presence propagation system in a preferred embodiment of the presentinvention;

FIG. 6 is a functional flowchart of the steps to logout an entity fromthe presence propagation system in a preferred embodiment of the presentinvention;

FIG. 7 is a functional flowchart of the steps to join an entity to agroup in the presence propagation system in a preferred embodiment ofthe present invention;

FIG. 8 is a functional flowchart of the steps to remove an entity from agroup in the presence propagation system in a preferred embodiment ofthe present invention;

FIG. 9 is a portion of a UserTable in a preferred embodiment of thepresent invention;

FIG. 10 is a portion of a UserTable in a preferred embodiment of thepresent invention;

FIG: 11 is a sample communications web page displayed to a registereduser of a preferred embodiment of the present invention;

FIG. 12 is a functional flowchart of the steps to update acommunications web page displayed to a registered user of a preferredembodiment of the present invention;

FIG. 13 is a sample communications web page displayed to a registereduser of a preferred embodiment of the present invention;

FIG. 14A is a functional flowchart of the steps to display acommunications web page to a requesting entity using a preferredembodiment of the present invention;

FIG. 14B is a functional flowchart of the steps to redirect an URL usinga preferred embodiment of the present invention;

FIG. 15 is a sample communications web page displayed to a requestingentity using a preferred embodiment of the present invention;

FIG. 16 is a sample communications web page displayed to a requestingentity using a preferred embodiment of the present invention;

FIG. 17 is a functional flowchart of the steps to transport typechat/instant messages using a preferred embodiment of the presentinvention;

FIG. 18 is a functional flowchart of the steps to transport a SIPmessage using a preferred embodiment of the present invention;

FIG. 19 is a sample communications web page displayed to a registereduser of a preferred embodiment of the present invention; and beendefined in the communications system, including a list of the groupsthat have been defined, passwords for those groups that require them,and a list of the members of each group. The first database 24 can beimplemented using any database application, such as Oracle or SQL-baseddatabases. Access to the first database 24 can also be managed throughany means. For example, in a Java environment, access can be handledusing a Java database connectivity (JDBC) interface.

The second database 26 is used to store non-persistent information forthe communications system. The second database 26 primarily consists oftwo data tables. The first data table contains the dynamic sessioninformation (to be explained below) for all users that are currentlyonline. The second data table contains a list of all of the groups thatcurrently have members online, and, for each such group, a list of allof the members that are currently online. Since the information in thesecond database 26 changes often and the information is accessedfrequently, the second database 26 is preferably stored as hash tablesin the memory of the backend server 1O. The second database 26 could beimplemented using any database application. The first database 24 andthe second database 26 may be combined into a single database, ifdesired.

The session manager servers 12 interact with the client devices 18 overthe network (e.g., Intranet or Internet). The session manager server 12includes a web server 28, a chat server 30 and a socket handler 32. Thesession manager servers 12 preferably communicate with the backendserver 10 using an inter-process communications protocol such as RemoteMethod Invocation (RMI). CORBA could also be used, as could any othercommunications protocol.

The web server 28 is used to serve web pages and their components to aweb browser or other application on a client device 18. The web server28 can be implemented in any programming language, but is preferablyimplemented as a Java Web Server (JWS) using, for example, Apache/Resinor WebLogic.

The chat server 30 is used to maintain the online presence (i.e.,heartbeat) of client devices 18 through an HTTP connection between theclient device 18 and the chat server 30. The chat server 30 is also usedto send messages to and receive messages from the client device 18through the HTTP connection. The chat server 30 can be implemented inany programming language, but is preferably implemented as a Java suchas VoIP, can be sent through a telephony network to a telephone 22.Thus, users of the communications system are able to initiate telephonecalls from client devices 18. Any existing gateway technology may beused for the gateway 20, such as, for example, Cisco VoIP routers.

Finally, the client devices 18 are the users of the communicationssystem. As noted above, the client devices 18 can be any entity—namelyany type of device with any type of an IP connection (e.g., wired,wireless, etc.) to a network. For example, as shown in FIG. 1, a clientdevice can be a laptop computer, a computer workstation, a PDA or anInternet enabled wireless phone. The client devices 18 interact with thecommunications system over a network, such as the Internet.

The client devices 18 preferably access the communications system eitherthrough a web browser 34 or through a download application 40. First,the communications system can be accessed through any web browser 34,such as Internet Explorer or Netscape Navigator or a Wireless MarkupLanguage (WML)/Handheld Device Markup Language (HDML) browser on anInternet enabled wireless device. As will be explained in detail below,the web browser 34 can display web pages 36 served from the web server28. Additionally, an applet 38 running on a web page 36 communicateswith the chat server 30. The applet 38 is tied to a particular web page36, and is preferably contained in a hidden frame in the web page 36. Itis also possible to use any other functionality in place of the applet38, such as, for example, an ActiveX control, to communicate with thechat server 30.

Alternatively, a download application 40 can be installed on a clientdevice 18 to allow the client device 18 to access the communicationssystem. The download application 40 has two components. First, theapplication 40 needs to be able to display web pages 42 served from theweb server 28. This can be accomplished either by launching a webbrowser already resident on the client device 18 or by providing a newapplication capable of interacting with the web server 28. The downloadapplication 40 also contains a CCHAT application 44 that communicateswith the chat server 30. The CCHAT application 44 is preferably writtenin C, although can be written in any programming language, and servesthe same function as the applet 38. Unlike the applet 38, however, theCCHAT application 44 is not linked to a particular web page 42.

Now that the overall architecture of a preferred embodiment of thecommunication system of the present invention has been described, thefunctionality of the communication system will be discussed. First, theprocess by which a user establishes and maintains online presence willbe discussed.

Initially, a user must register with the communications system. Inparticular, the user must pick a username and password that will be usedto allow the user to log into the system and thus maintain his presenceon line. Additionally, the user's username will be used to allow othersto communication with the user. For example, as discussed below, theHTTP URL http://pxcall.com/username will allow anyone, whether or notthey are registered to use the communications system, to communicatewith the user.

Once a user has registered with the communications system, the user canexploit the system. FIG. 2 shows the steps taken by a client device 18to establish and maintain online presence. First, the user logs on tothe communication system. If the client device 18 is running a webbrowser 34, the user enters an HTTP URL, such ashttp://www.planetexchange.com, and then enters a username and passwordto log into the system. If the user's username and password arerecognized as valid, the session manager server 12 to which the user hasbeen directed sends a web page 36 that includes the applet 38. Thesession manager server 12 also preferably sends a unique session ID, alarge random number that the client device 18 will use in allcommunications with the session manager server 12. This security measureassures that messages sent to the session manager 12 actually come fromthe client device 18. After receiving the session ID, the applet 38initiates an HTTP request—e.g.,http://hostboxid/jchat?me=usemame&id=sessionID . . . . , where hostboxidis the IP address of the session manager server 12, me is the user'susername, and id is the unique session ID for that current usersession—and waits to receive the requested web page. The applet 38 willcontinue to wait until the user logs out of the system or closes the webpage 36 and thus stops the execution of the applet 38. Additionally, aswill be discussed below, if a message is sent to the user, it isdelivered to the user as an HTTP response to this request. By making anHTTP request, the applet 38 maintains a “virtual” continuous HTTPconnection with the session manager server 12. This HTTP connection iswhat establishes and maintains the online presence of the user. As willbe described in detail below, scalability and optimization using thisHTTP-based approach for maintaining presence is preferably achieved bymaintaining the user connections without creating a new thread tomaintain and access each socket connection in a non-blocking manner.

It is also possible to maintain a user's presence (i.e., heartbeat)using HTTP in different manners. For example, multiple HTTP requests canbe used to maintain presence by having the applet 38 make periodic HTTPrequests to the session manager 12 to establish and maintain the onlinepresence of the user.

Alternatively, the above process can be automated if the client device18 is using the download application 40. For example, the client device18 can be set up so that the CCHAT application 44 executes when theclient device 18 is turned on. The CCHAT application 44 can thenautomatically log the client device 18 into the system and then initiatethe HTTP request to open an HTTP connection once the CCHAT application44 receives the session ID from the session manager server 12.

FIG. 3 shows how the session manager server 12 handles the HTTP requestfrom the client device 18. The HTTP request initiates a TCP/IP opensocket request, which is received by the low-level socket process 46,such as WinSock or Berkeley Sockets, on the session manager server 12.Normally, for the request to be handled in a non-blocking manner, itwould proceed through an Application Program Interface (API) layer 48before being sent to the application that will handle the open socketrequest, which in this case is the chat server 30. However, if an opensocket request is handled in this manner, a new thread (e.g., alightweight process in Unix, since Unix does not natively allow forthreads, just forked processes) is created and maintained for each opensocket connection. There is system overhead associated with the′creating and maintaining of thousands of threads, which would createproblems in scalability, since every user logging into thecommunications system would result in the creation of an additionalthread. Creating and maintaining a new thread with each open socketrequest would limit the number of simultaneous users per typical sessionmanager server 12 to approximately 3000.

To avoid the overhead associated with the creation of new threads, thecommunication system of the present invention uses the AltSock sockethandler 32. The AltSock socket handler 32 is a shim that handles theopen socket request instead of the API 48. The low-level socket process46 hands the open socket request to the AltSock socket handler 32. TheAltSock socket handler 32 accesses the socket simply by referencing itsfile descriptor in the socket table in the memory of the chat server 30,rather than creating a new thread to maintain and access the socket.Thus, there only needs to be a single thread to access all of thesockets, and thus all of the users, handled by the chat server 30 in anon-blocking manner. Using the socket handler 32, a typical sessionmanager server 12 can handle 10,000 simultaneous users.

The chat server 30 maintains a table in memory of all of the users thatare online that it is hosting. For each usemame, the table contains thesocket file descriptor of the HTTP connection for that user, as well asa counter that is used to keep the HTTP connection open. The table alsopreferably contains the user's dynamic session information, which willbe explained below. When a user logs into the system and the sockethandler 32 receives an open socket request, a new entry is added to thetable in the memory of the chat server 30 reflecting the new user,including dynamic session information, socket file descriptor, and acounter initialized to its start value. As will be discussed below, theusername and dynamic session information is also passed to the presencepropagation (PP) system so that others will be able to determine whetheror not the user is online, and, if so, will be able to communicate withthe user.

FIG. 4 shows how the chat server 30 maintains the HTTP connections withthe online users and thus maintains the online presence of those users.Every polling interval, which is preferably every four seconds, the chatserver 30 cycles through the list of online users. For each user, thechat server 30 first checks to see if the socket associated with theuser is still open. If the socket is not open, the user has logged offand the chat server 30 can remove the user from its table and can notifythe PP system that the user has logged off. If the socket is still open,the user's keep-alive counter is decremented. When the counter reacheszero (i.e., the keep-alive interval has been reached, which ispreferably 60 or 120 seconds), a byte is written to the socket to keepthe socket open, thereby keeping open the HTTP connection with the user.If the write operation fails, then the socket is not open. The user hasthus logged off and the chat server 30 can remove the user from itstable and can notify the PP system that the user has logged off.

There are thus three ways that a user can be logged out after havinglogged into the communications system. First, if the user intentionallylogs off of the network (e.g., by clicking on a logout link or closing aweb browser 34 or CCHAT application 44), a message can be sent from theclient device 18 to the chat server 30 to log the user out. If, however,a logout message is not sent to, or not received by, the chat server 30,the user can still be logged out when the chat server determines duringa polling interval that the socket associated the user is no longer openor determines during a keep-alive interval that it cannot write to thesocket associated with the user.

In the above-described process, the HTTP connection with a user servesas a heartbeat to let the chat server 30 know whether or not the user isstill online. Since the heartbeat is created and maintained using anHTTP connection, the heartbeat will function behind any proxy server orfirewall that allows HTTP traffic. Most firewalls and proxy serversallow such traffic since there is relatively little danger to a networkfrom HTTP transmissions.

Of course, one could implement the HTTP based heartbeat and •communications using processes other than the presently preferred methoddescribed above. For example, a first possible variation incorporatesthe current implementation without the AltSock socket handler 32. Such asystem would still work behind a firewall or proxy. In this variant, theopen socket requests are completely handled within the API layer 48, forexample within the Java Virtual Machine in a Java implementation, and anew thread is created and maintained for every connection by a clientdevice 18. This method has the undesirable consequence that a givensession manager 12 would have to maintain a thread for every connectedclient device 18.

A second variation uses HTTP as the transport, but uses a differentalgorithm for heartbeat and connection. In this variation, the usermakes periodic HTTP connections to the session manager 12 (perhaps every5-10 seconds), and the user's presence is determined by the absence of“httping” packets. After a user logs in, periodic “httping” packets aresent to the session manager 12, and a user's presence is deemed onlineuntil the packets stop. For example, this system could be implemented bystarting a timer when a user logs in. If the timer reaches zero, theuser is logged out. Otherwise if a keep-alive/httping packet isreceived, the timer is reset. This system will work behind a firewall orproxy. However, it is disadvantageous in that there is no way for thesession manager 12 to send messages to the user until the userreconnects to the session manager server 12 and provides the connectionpipe to communicate. Thus any updates, chats or other messages will bedelayed until the next connection cycle. When the user reconnects at thenext heartbeat interval, they will receive the messages. Moreimportantly, this system will not scale well at all, as by design itfloods itself with TCP connections under large loads.

A third variation uses HTTP to transport some messages, but uses one ormore additional TCP connections for additional signaling. In this typeof a system, various messages are sent over HTTP transport, and any ofthe previously mentioned socket handling algorithms or heartbeatmechanisms can be implemented. However, one or more additional TCPconnections (such as, for example using Telnet, SSH, or an unassignedTCP Port) is made to the session manager 12, in order to establishauthentication, or even to provide heartbeat and message passing. Thishybrid HTTP system will not work behind a firewall or proxy withoutspecial configurations that compromise the security of the firewall orproxy.

As discussed above, the PP system is notified when a user logs into orout of the communication system. This is important since the PP systemrunning on the backend server 10 plays a central role in the ability ofthe communications system to allow others to communicate with users ofthe communications system. The PP system will now be described.

As mentioned above, the second database 26 in the backend server 10maintains two data tables. The first data table (“UserTable”) maintainsa list of the dynamic session information for each user that iscurrently online. This dynamic session information includes:

User IP—the IP address of the entity (i.e., client device 18) from whichthe user is logged into the communications system.

-   -   Host Box Identifier—the IP address of the session manager server        12 that is hosting the user (i.e., the session manager 12 that        is maintaining the socket and HTTP connection with the user's        client device 18).    -   Port Number—the TCP port number on the client device 18 through        which the HTTP connection is maintained (typically port 80).

The dynamic session information also preferably includes:

-   -   Session ID—the unique session ID assigned to the user by the        chat server 30.    -   Group Info—the list of groups to which the user belongs.    -   Active Group—the group that the user currently has displayed on        the client device 18.

The second data table (“GroupTable”) maintains a list of the groups thatcurrently have members online together with a list of the members ineach group that are currently online. A group is simply a group of usersthat has been given a defined name in the communications system andwhich a user is capable of joining. For example, every user has apersonal address book—namely, the user's group of contacts that the userwishes to track the online presence of and communicate with.Additionally, groups can be companies, divisions, clubs, etc. Passwordprotection may be set up in the communications system to preventunauthorized users from joining groups or, as discussed below,displaying the communications page associated with the group.

FIG. 5 shows how the UserTable and GroupTable are updated by the PPsystem when a user logs onto the communication system. First, the chatserver 30 that is hosting the user sends a login message to the PPsystem along with the User IP, Host Box Identifier, Port Number, andSession ID. The PP system adds the user to the UserTable along with thedynamic session information provided by the chat server 30. The PPsystem then queries the first database 24 to get the list of the groupsto which the user belongs as well as the default active group of theuser. This additional information is added to the UserTable. Finally,the GroupTable is updated. For each group to which the user belongs, theuser is added to the list for that group in the GroupTable. If a groupto which the user belongs is not currently in the GroupTable, that groupis added to the GroupTable with the user listed as the only onlinemember.

FIG. 6 shows how the UserTable and GroupTable are updated when a userlogs off of the communication system. As previously discussed, the chatserver 30 notifies the PP system when a user logs off. FIGS. 7 and 8show how the UserTable and GroupTable are updated when a user joins agroup and when a user 1eaves a group, respectively. The chat server 30notifies the backend server 10 about the change in group membership. Thefirst database 24 and the data tables of the second database 26 areupdated. Since the procedures of FIGS. 6-8 are very similar to thosediscussed above for FIG. 5, they are not described in detail here.

Thus, the PP system allows the communication system to track the currentonline presence of users including the dynamic session information forall online users. The PP system also tracks which groups currently havemembers online and which members in those groups are currently online.For example, FIG. 9 shows a portion of a UserTable at 10:00 a.m.reflecting three users logged in to the system. User 1 has a set ofcurrent dynamic information stored in the UserTable. Similarly, user2and user3 have their current dynamic session information stored in theUserTable. FIG. 10 represents the same UserTable at 3:00 p.m. As seen inthe table, user1 has logged out of the system and has subsequentlylogged back into the system between 10:00 a.m. and 3:00 p.m. using adifferent client device 18. Accordingly, the dynamic session informationfor user1 in the UserTable has changed. User2 has been continuouslylogged in to the system from the same client device 18, so the dynamicsession information in the UserTable for user2 is the same in FIGS. 9and 10. User3 has logged off of the Internet and has not logged back in.Accordingly, user3 has no current dynamic session information in theUserTable. Finally, user4 has logged in to the system between 10:00 a.m.and 3:00 p.m., and thus has dynamic session information in the UserTablein FIG. 10.

Next, the use of the online presence information, and particularly thedynamic session information, maintained by the PP system in facilitatingcommunication with users of the communications system will be described.

First, when a user logs into the communications system, a web page 36 or40 is preferably displayed apart from the applet 38 or CCHAT application44 that establishes and maintains the presence of the user using an HTTPconnection. FIG. 11 shows a sample communications web page 50 that wouldbe displayed to user1 after logging into the system. The web page 50displays the members of user1 's active group (in this case, user1 'saddress book) and presents communications options to user 1 based on theonline presence of the members of user1 's address book. Preferably,four communications options are presented: chat, PC to PC communication,PC to Phone communication, and the ability to leave a message for auser. Of course, a subset of these communications options could bepresented, or other communications options could be displayed. Moreover,the web page 50 could also take any form so long as it presents a means(in the form of hyperlinks, images, etc.) to initiate communicationsoptions with the user.

Chat is a real-time type chat or instant message capability. It can onlybe used with a user that is currently online. Thus, in FIG. 11, whereuser1 and user4 are online, a box appears indicating that user1 can chatwith those users. Further, since user2 and user3 are offline, a lineappears on the web page 50 rather than a box, indicating that the chatcommunication format is not available with those users. Clicking on abox on the web page 40 will initiate the chosen communications optionwith the indicated user. For example, clicking on box 52 will start achat session with user4. Type chat/instant messaging using thecommunications system of the current invention will be explained indetail below.

PC to PC communication is real-time voice and/or video conferencing. Inorder to use this communications option, a client device 18 must beequipped with a sound card and microphone for voice communication and avideo camera for video communication. This option is also only availablewith users that are currently online (e.g., user1 and user4 in FIG. 11).When a user clicks to start a PC to PC call, the communications systemlaunches an appropriate client application on the client device such asMicrosoft NetMeeting or another Internet based communications clientsuch as an H323 client or a T120 client. The communications system usesthe dynamic session information stored in the UserTable—namely, User IPand possibly Port Number—to put the correct addressing information intothe client application to permit the PC to PC call to be connected.

PC to Phone communication is real-time VoIP communication using thegateway 20 to connect voice communication between a client device 18 anda telephone 22 at a telephone number stored in the first database 24. Ifa user has selected a telephone number where PC to Phone calls should bedirected (which is stored in the first database 24), a box will appearin the web page 50, allowing PC to Phone communication to be selectedfor that user. For example, in FIG. 11, user 1, user3 and user4 havestored phone numbers where they can be reached. A user does not have tobe online for a PC to Phone call to be initiated. Thus, in FIG. 11, abox appears for PC to Phone communication with user3, even though user3is not currently online. When a user clicks to initiate a PC to Phonecall, the communications system launches an appropriate clientapplication on the client device 18 such as, for example, MicrosoftNetMeeting. The telephone number stored for the user is retrieved fromthe first database 24 and the call is routed to the telephony networkusing the gateway 20.

Finally, the message box, which is available for all users whether ornot they are currently online, allows a user to leave a text orvoice/video message for the indicated user. The message, after beingrecorded or typed by the user, will be stored for the recipient in thefirst database 24. The recipient can then retrieve the message and playit back by clicking on the messages link on the recipient'scommunications web page 50.

FIG. 12 shows how a communications web page 50 is updated when a userlogs on, logs off, joins a group or leaves a group. The updates areprocessed and displayed immediately, giving users of the communicationssystem of the present invention a real-time indication of the onlinepresence of the members of the active group displayed on theircommunications web pages 50. First, as described above with respect toFIGS. 5-8, the UserTable and GroupTable are updated as a result of auser logging in, logging out, joining a group or leaving a group. Next,the PP system creates an update list of the online member(s) to benotified sorted by session manager server 12 (i.e., host box). To avoidsending unnecessary update information, the PP system checks the ActiveGroup for each member to make sure that the update applies to thisgroup. For example, looking at FIG. 11, if user2 came online and user1's Active Group is the Address Book (as shown in FIG. 11), the updateshould go to user1. If, however, user 1 's displayed Active Group wasdifferent and if that Active Group did not include user2, then user1should not receive an update that user2 came online.

Once the update list for each session manager server 12 is created, thelists are sent to the appropriate session manager server 12. Eachsession manager server 12 receives the update lists for the member(s) itis hosting and places update messages in an update queue for each memberthat is stored in the chat server 30. The chat server 30 then sends anHTTP encoded update message to the applet 38 or CCHAT application 44 ofeach member that has an update message stored in its update queue. Ifthe update list was created from a user joining or leaving a group, arefresh update message is sent to the applets 38 or CCHAT applications44 instead of an update message. For example, looking again at FIG. 11,if user2 comes online and user4 goes offline, the update list sent tothe session manager server 12 hosting user1 would include an updatemessage for user1 that user2 came online and user4 went offline. Anupdate message would then be sent to the applet 38 or CCHAT application44 of the client device 18 for user1.

The update messages are sent from the chat server 30 to the applet 38 orCCHAT application 44 using the same socket and HTTP connection that havebeen established to maintain the online presence of the member and, aswill be explained below, to send other types of messages such as textmessages or SIP messages. The update messages can be of any format, butare preferably of the form “msg update updatetype,” where updatetyperepresents the type of update to be performed (e.g., update single userpresence, update User IP address, refresh page, etc.)

When an applet 38 or CCHAT application 44 receives a refresh updatemessage, the applet 38 or CCHAT application 44 causes the web page 36 orweb page 40, respectively, to refresh. When the web server 28 sends theupdated web page 36 or 40, it will include a new line for the user thatwas added to the displayed active group of the member if a user joinedthe group. If a user left the group, the updated web page 36 or 40 willhave deleted the line for the user that was removed from the displayedactive group of the member.

If, however, the applet 38 or CCHAT application 44 receives an updatemessage, it is unnecessary to refresh the entire web page, since theusers displayed on the communications web page 50 have not changed. Onlythe online status of the users has changed, and thus only the boxesdisplayed on the communications web page 50 need to be changed.Accordingly, upon receiving an update message, the applet 38 or CCHATapplication 44 calls update.jsp, a hidden frame on the member'scommunications web page 50. In response, the web server 28 for themember gets the update messages in the update queue for the member fromthe chat server 30 and dynamically generates a web page containingJavaScript designed to change the images and links associated with theusers that have logged in and out on the member's communications webpage 50.

For example, looking again at FIG. 11, in order to process the updatemessages for user 1 that user2 has come online and user4 has goneoffline, the web server would generate JavaScript such as: runUpdate( ){ change image for chat-user 2 change link for chat-user 2 change imagefor call-user 2 change link for call-user 2 change image for chat-user 4change link for chat-user 4 change image for call-user 4 change link forcall-user 4 }

The web page generated by the web server 28 is then sent to the member,and the JavaScript runs on-load, which executes the dynamic scripts andupdates the links and images on the communications web page 50. Forexample, if the above JavaScript was sent to the communications web page50 as shown in FIG. 11, the communications web page 50 would be changedas shown in FIG. 13. User2 is now shown as being online, and the chatand PC to PC options have been activated, while user4 is now shown asbeing offline and the chat and PC to PC options have been deactivated.

The advantage of performing updates in this manner is that the entirecommunications web page 50 does not need to be refreshed every time auser comes online or offline. This is particularly advantageous when auser has an Active Group displayed that has many members. Of course, aJava applet within the communications web page 50 could also be used toperform updates in this manner, without the use of JavaScript.

FIG. 19 shows a sample communications web page 50 that would bedisplayed to user1 after logging in to the system in another preferredembodiment of the communication system of the present invention. The webpage 50 is identical to that shown in FIG. 11, except a fifthcommunication option is presented—PC to wireless device.

PC to wireless device communications is two-way text messaging between aclient device 18 and an Internet enabled wireless device. If a user hasselected an Internet-enabled wireless device where PC to wireless devicecommunications should be directed (which is stored in the first database24), a box will appear in the web page 50, allowing PC to wirelessdevice communication to be selected for that user. For example, in FIG.11, user1, user2 and user4 have stored wireless devices where they canbe reached. A user does not have to be online for a PC to wirelessdevice communication to be initiated. Thus, in FIG. 19, a box appearsfor PC to wireless device communication with user2, even though user2 isnot currently online. As with the other communications options describedabove, clicking on a box on the web page 50 will initiate the chosencommunications option with the indicated user. For example, clicking onbox 52 will start a PC to wireless device communication with user4. PCto wireless device communication using the communications system of thecurrent invention will be explained in detail below.

The communications system of the present invention also allowsrequesters that are not registered users of the communications system ofthe present invention to communicate with users of the system. Everyregistered user and group gets at least one unique static HTTP URL whichis linked with the dynamic session information stored in the seconddatabase 26 of the backend server 10. The HTTP URL can thus be used todetermine the current online presence of the user associated with theURL as well as facilitate communication with the user associated withthe HTTP URL.

The HTTP URL can take any form so long as it uniquely identifies theuser or group. For example:

-   -   http://pxcall.com/usemame    -   http://pxcall.com/groupname,    -   http://pxcall.com/SecondaryName/username,    -   http://PrimaryName.pxcall.com/SecondaryName/username would all        be valid URLs. Additionally, it is possible to have aliases        defined, such that multiple HTTP URLs would all be associated        with the same user and all perform in the same manner. For        example, http://pxcall.com/UserName,        http://pxcall.com/UserPhoneNumber and        http://pxcall.com/UserEmailAddress could all be associated with        the same user and all perform the same when used to determine        the current online presence of the user or facilitate        communication with the user.

Preferably, the URL is typed into a web browser by the requestor inorder for the requestor to determine the current online presence of theuser associated with the URL or facilitate communication with the userassociated with the URL. Of course, the URL can also be used indifferent manners to achieve the same communication objectives. Forexample, the URL's can be stored in a user's Favorite List or asBookmarks. Additionally, the URL's can be placed as hyperlinks on webpages or associated with images or other graphics on web pages and thuscan be accessed by clicking on the hyperlink, image or other graphic.

FIGS. 14A and 14B show how a requestor uses the HTTP URL. First, therequestor enters the URL into a web browser on a client device 18connected to the Internet or other network, or clicks on or otherwiseactivates a hyperlink associated with the URL. A redirector (not shown)parses the URL and redirects the client to one of the session managerservers 12 in an appropriate format. For example,http://pxcall.com/usemame may be translated intohttp://planetexchange.com/callIjsp?name=username. The redirectorprovides standard URL redirection and may be located on any server, suchas, for example, the backend server 10, the session manager server 12 orsome other independent server.

As shown in FIG. 14B, the original URL is passed to the redirector,which translates the URL. The redirector then sends an HTTP 301 Response(redirect URL) to the client along with the translated URL. The clientthen is directed to the session manager server 12. The web server 28next queries the first database 24 to see if the user or group sought bythe requestor requires password access to its communications web page.If so, the requestor is prompted to enter a password. If an incorrectpassword is supplied, the requestor is denied access to thecommunications web page. Otherwise, the web server 28 queries the seconddatabase 26 to determine the online presence of the user or the membersof the requested group. The web server 28 then presents a communicationsweb page 50 to the client, showing the online presence information andpresenting communications options to the requestor to facilitatecommunication with the user or members of the group.

If the requestor entered the URL of an individual user, a communicationsweb page 50 such as shown in FIG. 15 will be presented. The web page 50,including the functionality of the links on the page is analogous tothat discussed above with respect to FIG. 11. Alternatively, as shown inFIG. 14, if the user is not currently online, the requestor may bepresented with a web page 50 that only allows the requestor to leave amessage for the user. For example, such a web page may have a textmessage or prerecorded voice/video message from the user requesting thata message be left on the page, the web page also presenting links toleave text or voice/video messages.

If the requestor entered the URL of a group, a communications web page50 such as shown in FIG. 16 will be presented. The web page 50,including the functionality of the links on the page is analogous tothat discussed above with respect to FIG. 11.

As shown in FIG. 14, after presenting the web page 50 on the requestor'sbrowser, the web server starts a communication applet that is analogousto the applet 38 discussed in detail above. This applet opens a socketand HTTP connection between the web server and the requestor's webbrowser that is analogous to the heartbeat maintained with registeredusers of the communications system. This socket and HTTP connection areused to facilitate communication with the requestor, particularly fortype chat/instant messaging.

As discussed above, one of the forms of communication facilitated by thecommunications system of the present invention is type chat /instantmessaging. This communication option is presented to registered users ontheir communications web pages 50 as shown in FIG. 11 and is alsopresented to requestors on their communications web pages 50 as shown inFIGS. 15 and 16. FIG. 17 shows how type chat/instant messagingpreferably is carried out using the communications system of the presentinvention. First, the requestor clicks on a link to initiate a chat witha registered user that is currently online. This action causes an HTTPrequest to be sent to the session manager server 12 hosting the user.This request is of the form: http://hostboxip/initchat?me= . . . to= . .. id= . . . , where me is the requestor, to is the recipient and id isthe session id of the requestor. The chat server 30 on the sessionmanager server 12 hosting the user writes an initChat message to be sentthe applet 38 or CCHAT application 44 on the client device 18 of theuser. This message is preferably of the form “msg initChat” although itcan be of any form. Similarly, the chat server 30 on the session managerserver 12 hosting the requestor writes an initChat message to be sentthe applet 38 or CCHAT application 44 on the client device 18 of theuser. If the requestor is not a registered user, then the message willbe sent to the applet 38 associated with the requestor's web browser.The initChat messages cause the applet 38 or CCHAT application 44 toopen a chat window or box on the client device 18 of the user andrequestor.

Chat messages are sent to the chat server 30 on the session managerserver 12 of the receiving party using HTTP requests that are preferablyof the form HTTP POST to /chat with elements me= . . . . , msg=textmessage, where me is the sender, sessionlD is the session ID of thesender and msg is the text message to be sent. These requests open a newsocket for the transmission that is immediately closed after the post.The chat messages are received by the chat server 30, where they arerelayed to the receiving party by writing the bytes to the socket aspart of the HTTP response that is the user connection between the chatserver 30 and the applet 38 or CCHAT application 44. Upon receipt, thechat message is displayed in the chat window or box.

Preferably, upon receipt of the message, the socket, and thus the HTTPconnection between the receiving party and the chat server 30, isclosed. The receiving party reestablishes its socket connection to thechat server 30 via another HTTP connection using the same process toestablish a connection as explained above. Of course, the existingsocket could be kept open, thereby removing the need to reestablish thesocket and HTTP connection.

The type chat/instant messaging of the communications system of thepresent invention is advantageous in that it is completely HTTP based.Accordingly, it will allow messages to be sent to any client device 18,whether or not it is behind a proxy server or firewall. Moreover, thetype chat/instant messaging does not require any proprietary download orproprietary format for the transmission of messages or the determinationof the online presence information of the parties. The system is thuscompletely open and can be used by any client device 18 with a webbrowser connected to a network.

As discussed above, another one of the forms of communicationfacilitated by the communications system of the present invention istwo-way text messaging with Internet enabled wireless devices. Thiscommunication option is presented to registered users on theircommunications web pages 50 as shown in FIG. 19 and could also bepresented to requestors on their communications web pages 50 such asthose shown in FIGS. 15 and 16. FIG. 20 shows how text messaging withInternet enabled wireless devices preferably is carried out using thecommunications system of the present invention. First, the requestorclicks on a link to initiate two-way text messaging with a wirelessdevice. This action causes an initChat message to be sent from the chatserver 30 hosting the requestor to the wireless device that includes anURL that identifies the chat server 30. This message is sent to thewireless device using a wireless telephony network. For example, themessage can be sent to a Wireless Application Protocol (WAP) Gatewaysuch as phone.com. Alternatively, the message can be sent to thewireless device using Short Message Service (SMS) messaging.

The chat server 30 next checks to see if the message is successfullydelivered to the wireless device. If not, the chat server 30 sends amessage to the requestor that the wireless device is not available. Ifthe message is delivered, the chat server 30 sends an initChat messageto the applet 38 or CCHAT application 44 on the client device 18 of therequestor. This message is the same as described above with respect totype chat in order to open a chat window or box on the client device 18of the requestor.

The user of the wireless device can then respond to the initChat messagesent to the wireless device to initiate two-way messaging with therequestor. The wireless device responds by making an HTTP request to theURL sent in the initChat message. This request can be made, for example,using a WML/HDML browser on the wireless device. The request is used toestablish and maintain a socket between the wireless device and the chatserver 30 using the identical process as explained above with respect toother client devices 18. The socket is also maintained using the samemethod as described above. Messages can then be sent back and forthbetween the requestor and the wireless device using HTTP requests asdescribed above with respect to type chat/instant messaging. Themessages are displayed in the requestor's chat window or box, and aredisplayed on the wireless device using appropriate WML/HDML formatting.

The socket and HTTP connection established between a chat server 30 andthe applet 38 or CCHAT application 44 on the client device 18 of aregistered used can also be used to transport other types of informationacross proxy servers and firewalls that otherwise would not be able tocross such barriers. For example, Session Initiation Protocol (SIP) hasgenerated a tremendous amount of recent interest. However, SIP messagescannot pass through a proxy server/firewall barrier, as they can beeither UDP or TCP based. The communications system of the presentinvention could be used to provide a means of transporting SIP messagesacross a proxy server/firewall. FIG. 18 shows how the transportation ofSIP messages preferably is carried out using the communications systemof the present invention. The chat server 30, which is placed outside ofa user's proxy server/firewall, can act as a SIP proxy for the user. Asshown in FIG. 18, the chat server 30 receives a SIP request for theuser. The chat server 30 then relays the request to the user using thesocket and HTTP connection with the user as described above. Forexample, the chat server 30 preferably sends a message of the form “msgsiprep reqtype”, where reqtype is the type of SIP request received bythe chat server 30. When this message is received by the applet 38 orCCHAT application 44 on the client device 18 of the user, the applet 38or CCHAT application 44 could then execute some form of SIP clientapplication on the client device 18 to respond/process the SIP request.Of course, the SIP functionality could be built into the applet 38 orCCHAT application 44 rather than a separate application. In this way,SIP messages can be sent to users using HTTP connections and thus canpass across a proxy server/firewall.

The present invention may be implemented with any combination ofhardware and software. If implemented as a computer-implementedapparatus, the present invention is implemented using means forperforming all of the steps and functions described above. The presentinvention also can be included in an article of manufacture (e.g., oneor more computer program products) having, for instance, computeruseable media. The media has embodied therein, for instance, computerreadable program code means for providing and facilitating themechanisms of the present invention. The article of manufacture can beincluded as part of a computer system or sold separately.

It will be appreciated by those skilled in the art that changes could bemade to the embodiments described above without departing from the broadinventive concept thereof. It is understood, therefore, that thisinvention is not limited to the particular embodiments disclosed, but itis intended to cover modifications within the spirit and scope of thepresent invention.

1. A computer-implemented method of facilitating communication with anentity over a network, the method comprising: (a) associating a staticHTTP URL with the entity; (b) linking the URL with communicationsinformation reflecting the entity's current online presence includingthe entity's dynamic session information as determined using the HTTPprotocol; and (c) using the URL and the communications information tofacilitate communication with the entity.
 2. The method of claim 1wherein the dynamic session information includes the entity's currentdynamic IP address and host box identifier.
 3. The method of claim 2wherein the dynamic session information includes the entity's TCP portnumber on which to be reached.
 4. The method of claim 2 wherein thedynamic session information includes the entity's session ID.
 5. Themethod of claim 1 wherein step (c) is performed by displaying acommunications web page associated with the entity, the communicationsweb page reflecting the entity's current online presence and includinghyperlinks to facilitate communication with the entity based on theentity's dynamic session information.
 6. The method of claim 5 whereinthe communications web page is displayed as a result of the HTTP URLbeing typed into a web browser.
 7. The method of claim 5 wherein thecommunications web page is displayed as a result of clicking on orotherwise activating a hyperlink associated with the HTTP URL.
 8. Themethod of claim 1 wherein multiple forms of communication with theentity are facilitated.
 9. The method of claim 8 wherein the forms ofcommunication include type chat/instant messaging, voice communicationover a computer network, video communication over a computer network,voice communication from a computer network to a telephone network andtwo-way text messaging to Internet enabled wireless devices.
 10. Themethod of claim 1 wherein the static HTTP URL contains entity-selectedinformation.
 11. The method of claim 1 further comprising: (d)associating additional, different static HTTP URLs with the entity; (e)linking the additional URLs with the same communications informationreflecting the entity's current online presence including the entity'sdynamic session information as determined using the HTTP protocol; and(f) using the additional URLs and the communications information tofacilitate communication with the entity.
 12. A computer-implementedmethod of facilitating communication over a network with one or moremembers of a group of entities, the group comprising a plurality ofentities, the method comprising: (a) associating a static HTTP URL withthe group; (b) linking the URL with communications informationreflecting each of the members' current online presence including eachof the members' dynamic session information as determined using the HTTPprotocol; and (c) using the URL and the communications information tofacilitate communication with one or more members of the group.
 13. Themethod of claim 12 wherein the dynamic session information includes eachof the members' current dynamic IP address and host box identifier. 14.The method of claim 13 wherein the dynamic session information includeseach of the members' TCP port number on which to be reached.
 15. Themethod of claim 13 wherein the dynamic session information includes eachof the members' session ID.
 16. The method of claim 12 wherein step (c)is performed by displaying a communications web page associated with thegroup, the communications web page reflecting each of the members'current online presence and including hyperlinks to facilitatecommunication with each of the members based on the members' dynamicsession information.
 17. The method of claim 16 wherein thecommunications web page is displayed as a result of the HTTP URL beingtyped into a web browser.
 18. The method of claim 16 wherein thecommunications web page is displayed as a result of clicking on orotherwise activating a hyperlink associated with the HTTP URL.
 19. Themethod of claim 12 wherein multiple forms of communication with each ofthe members of the group are facilitated.
 20. The method of claim 19wherein the forms of communication include type chat/instant messaging,voice communication over a computer network, video communication over acomputer network, voice communication from a computer network to atelephone network and two-way text messaging to Internet enabledwireless devices.
 21. The method of claim 12 wherein the static HTTP URLcontains group-selected information.
 22. The method of claim 12 furthercomprising: (d) associating additional, different static HTTP URLs withthe group; (e) linking the additional URLs with the same communicationsinformation reflecting each of the members' current online presenceincluding each of the members' dynamic session information as determinedusing the HTTP protocol; and (f) using the additional URLs and thecommunications information to facilitate communication with one or moremembers of the group.
 23. A computer-implemented method of determiningthe current online presence of an entity on a computer network, themethod comprising: (a) associating a static HTTP URL with the entity;(b) linking the URL with communications information reflecting theentity's current online presence including the entity's dynamic sessioninformation as determined using the HTTP protocol; and (c) determiningthe current online presence of the entity using the URL and thecommunications information.
 24. The method of claim 23 wherein thedynamic session information includes the entity's current dynamic IPaddress and host box identifier.
 25. The method of claim 24 wherein thedynamic session information includes the entity's TCP port number onwhich to be reached.
 26. The method of claim 24 wherein the dynamicsession information includes the entity's session ID.
 27. The method ofclaim 23 wherein the static HTTP URL contains entity-selectedinformation.
 28. An article of manufacture for facilitatingcommunication with an entity over a network, the article of manufacturecomprising a computer-readable medium holding computer-executableinstructions for performing a method comprising: (a) associating astatic HTTP URL with the entity; (b) linking the URL with communicationsinformation reflecting the entity's current online presence includingthe entity's dynamic session information as determined using the . HTTPprotocol; and (c) using the URL and the communications information tofacilitate communication with the entity.
 29. The article of manufactureof claim 28 wherein the dynamic session information includes theentity's current dynamic IP address and host box identifier.
 30. Thearticle of manufacture of claim 29 wherein the dynamic sessioninformation includes the entity's TCP port number on which to bereached.
 31. The article of manufacture of claim 29 wherein the dynamicsession information includes the entity's session ID.
 32. The article ofmanufacture of claim 28 wherein step (c) is performed by displaying acommunications web page associated with the entity, the communicationsweb page reflecting the entity's current online presence and includinghyperlinks to facilitate communication with the entity based on theentity's dynamic session information.
 33. The article of manufacture ofclaim 32 wherein the communications web page is displayed as a result ofthe HTTP URL being typed into a web browser.
 34. The article ofmanufacture of claim 32 wherein the communications web page is displayedas a result of clicking on or otherwise activating a hyperlinkassociated with the HTTP URL.
 35. The article of manufacture of claim 28wherein multiple forms of communication with the entity are facilitated.36. The article of manufacture of claim 35 wherein the forms ofcommunication include type chat/instant messaging, voice communicationover a computer network, video communication over a computer network,voice communication from a computer network to a telephone network andtwo-way text messaging to Internet enabled wireless devices.
 37. Thearticle of manufacture of claim 28 wherein the static HTTP URL containsentity-selected information.
 38. The article of manufacture of claim 28wherein the computer-executable instructions perform a method furthercomprising: (a) associating additional, different static HTTP URLs withthe entity; (b) linking the additional URLs with the same communicationsinformation reflecting the entity's current online presence includingthe entity's dynamic session information as determined using the HTTPprotocol; and (c) using the additional URLs and the communicationsinformation to facilitate communication with the entity.
 39. An articleof manufacture for facilitating communication over a network with one ormore members of a group of entities, the group comprising a plurality ofentities, the article of manufacture comprising a computer-readablemedium holding computer-executable instructions for performing a methodcomprising: (a) associating a static HTTP URL with the group; (b)linking the URL with communications information reflecting each of themembers' current online presence including each of the members' dynamicsession information as determined using the HTTP protocol; and (c) usingthe URL and the communications information to facilitate communicationwith one or more members of the group.
 40. The article of manufacture ofclaim 39 wherein the dynamic session information includes each of themembers' current dynamic IP address and host box identifier.
 41. Thearticle of manufacture of claim 40 wherein the dynamic sessioninformation includes each of the members' TCP port number on which to bereached.
 42. The article of manufacture of claim 40 wherein the dynamicsession information includes each of the members' session ID.
 43. Thearticle of manufacture of claim 39 wherein step (c) is performed bydisplaying a communications web page associated with the group, thecommunications web page reflecting each of the members' current onlinepresence and including hyperlinks to facilitate communication with eachof the members based on the members' dynamic session information. 44.The article of manufacture of claim 43 wherein the communications webpage is displayed as a result of the HTTP URL being typed into a webbrowser.
 45. The article of manufacture of claim 43 wherein thecommunications web page is displayed as a result of clicking on orotherwise activating a hyperlink associated with the HTTP URL.
 46. Thearticle of manufacture of claim 39 wherein multiple forms ofcommunication with each of the members of the group are facilitated. 47.The article of manufacture of claim 46 wherein the forms ofcommunication include type chat/instant messaging, voice communicationover a computer network, video communication over a computer network,voice communication from a computer network to a telephone network andtwo-way text messaging to Internet enabled wireless devices.
 48. Thearticle of manufacture of claim 39 wherein the static HTTP URL containsgroup-selected information.
 49. The article of manufacture of claim 39wherein the computer-executable instructions perform a method furthercomprising: (a) associating additional, different static HTTP URLs withthe group; (b) linking the additional URLs with the same communicationsinformation reflecting each of the members' current online presenceincluding each of the members' dynamic session information as determinedusing the HTTP protocol; and (c) using the additional URLs and thecommunications information to facilitate communication with one or moremembers of the group.
 50. An article of manufacture for determining thecurrent online presence of an entity on a computer network, the articleof manufacture comprising a computer-readable medium holdingcomputer-executable instructions for performing a method comprising: (a)associating a static HTTP URL with the entity; (b) linking the URL withcommunications information reflecting the entity's current onlinepresence including the entity's dynamic session information asdetermined using the HTTP protocol; and (c) determining the currentonline presence of the entity using the URL and the communicationsinformation.
 51. The article of manufacture of claim 50 wherein thedynamic session information includes the entity's current dynamic IPaddress and host box identifier.
 52. The article of manufacture of claim51 wherein the dynamic session information includes the entity's TCPport number on which to be reached.
 53. The article of manufacture ofclaim 51 wherein the dynamic session information includes the entity'ssession ID.
 54. The article of manufacture of claim 50 wherein thestatic HTTP URL contains entity-selected information.
 55. Acomputer-implemented apparatus for facilitating communication with anentity over a network, the apparatus comprising: (a) means forassociating a static HTTP URL with the entity; (b) means for linking theURL with communications information reflecting the entity's currentonline presence including the entity's dynamic session information asdetermined using the HTTP protocol; and (c) means for using the URL andthe communications information to facilitate communication with theentity.
 56. The apparatus according to claim 55 wherein the dynamicsession information includes the entity's current dynamic IP address andhost box identifier.
 57. The apparatus according to claim 56 wherein thedynamic session information includes the entity's TCP port number onwhich to be reached.
 58. The apparatus according to claim 56 wherein thedynamic session information includes the entity's session ID.
 59. Theapparatus according to claim 55 wherein the means for using the URL andthe communications information comprise means for displaying acommunications web page associated with the entity, the communicationsweb page reflecting the entity's current online presence and includinghyperlinks to facilitate communication with the entity based on theentity's dynamic session information.
 60. The apparatus according toclaim 59 wherein the communications web page is displayed as a result ofthe HTTP URL being typed into a web browser.
 61. The apparatus accordingto claim 59 wherein the communications web page is displayed as a resultof clicking on or otherwise activating a hyperlink associated with theHTTP URL.
 62. The apparatus according to claim 59 wherein multiple formsof communication with the entity are facilitated.
 63. The apparatusaccording to claim 62 wherein the forms of communication include typechat/instant messaging, voice communication over a computer network,video communication over a computer network, voice communication from acomputer network to a telephone network and two-way text messaging toInternet enabled wireless devices.
 64. The apparatus according to claim55 wherein the static HTTP URL contains entity-selected information. 65.The apparatus according to claim 55 further comprising: (a) means forassociating additional, different static HTTP URLs with the entity; (b)means for linking the additional URLs with the same communicationsinformation reflecting the entity's current online presence includingthe entity's dynamic session information as determined using the HTTPprotocol; and (c) means for using the additional URLs and thecommunications information to facilitate communication with the entity.66. A computer-implemented apparatus for facilitating communication overa network with one or more members of a group of entities, the groupcomprising a plurality of entities, the apparatus comprising: (a) meansfor associating a static HTTP URL with the group; (b) means for linkingthe URL with communications information reflecting each of the members'current online presence including each of the members' dynamic sessioninformation as determined using the HTTP protocol; and (c) means forusing the URL and the communications information to facilitatecommunication with one or more members of the group.
 67. The apparatusaccording to claim 66 wherein the dynamic session information includeseach of the members' current dynamic IP address and host box identifier.68. The apparatus according to claim 67 wherein the dynamic sessioninformation includes each of the members' TCP port number on which to bereached.
 69. The apparatus according to claim 67 wherein the dynamicsession information includes each of the members' session ID.
 70. Theapparatus according to claim 66 wherein the means for using the URL andthe communications information comprise means for displaying acommunications web page associated with the group, the communicationsweb page reflecting each of the members' current online presence andincluding hyperlinks to facilitate communication with each of themembers based on the members' dynamic session information.
 71. Theapparatus according to claim 70 wherein the communications web page isdisplayed as a result of the HTTP URL being typed into a web browser.72. The apparatus according to claim 70 wherein the communications webpage is displayed as a result of clicking on or otherwise activating ahyperlink associated with the HTTP URL.
 73. The apparatus according toclaim 66 wherein multiple forms of communication with each of themembers of the group are facilitated.
 74. The apparatus according toclaim 73 wherein the forms of communication include type chat/instantmessaging, voice communication over a computer network, videocommunication over a computer network, voice communication from acomputer network to a telephone network and two-way text messaging toInternet enabled wireless devices.
 75. The apparatus according to claim66 wherein the static HTTP URL contains group-selected information. 76.The apparatus according to claim 66 further comprising: (a) means forassociating additional, different static HTTP URLs with the group; (b)means for linking the additional URLs with the same communicationsinformation reflecting each of the members' current online presenceincluding each of the members' dynamic session information as determinedusing the HTTP protocol; and (c) means for using the additional URLs andthe communications information to facilitate communication with one ormore members of the group.
 77. A computer-implemented apparatus fordetermining the current online presence of an entity on a computernetwork, the apparatus comprising: (a) means for associating a staticHTTP URL with the entity; (b) means for linking the URL withcommunications information reflecting the entity's current onlinepresence including the entity's dynamic session information asdetermined using the HTTP protocol; and (c) means for determining thecurrent online presence of the entity using the URL and thecommunications information.
 78. The apparatus according to claim 77wherein the dynamic session information includes the entity's currentdynamic IP address and host box identifier.
 79. The apparatus accordingto claim 78 wherein the dynamic session information includes theentity's TCP port number on which to be reached.
 80. The apparatusaccording to claim 78 wherein the dynamic session information includesthe entity's session ID.
 81. The apparatus according to claim 77 whereinthe static HTTP URL contains entity-selected information.